1. If I'm understanding this PR correctly, the behaviour of this function changes? So if I had a code get_valid_resource_id(resource_type_id) and upgraded bevy, the function call would start returning unexpected results, correct? In that case, I think it would be better to remove this function completely instead of just deprecating it (users will have to change the code anyways).
2. If I just have a TypeId and don't know the type R, is there still some way for me to check if it's registered? (for example, I could get the type IDs from iterating over the whole TypeRegistry registrations and checking for ReflectResource type data). If not, one option would be to add these function to ReflectResource.

(the same applies to get_resource_id)

I think you're right, but I'll leave it to a clean-up PR. I really want to start wrapping this up.

This seems a pretty big footgun IMO and not something to clean up later on.

This seems a pretty big footgun IMO and not something to clean up later on.

I don't think silently despawning an existing resource entity / replacing it is something we should allow as part of normal flows. This would break any existing references to the resource entity, including things like relationships. It would also erase any additional context we might add to the entity (ex: marker components). I personally think we are better off despawning the new entity, losing the new value, and logging an error. We lose many of the benefits of representing resources as entities if we can't rely on the stability of their entity id or their components.

(I am aware of how this behavior would interact with scenes, see my other comment)

Using QueryState here feels very "heavy" for what we're doing here (QueryState is a "large" type, maintaining the extra access sets takes work, the query lifecycle has overhead to keep the matching archetype list in place, we don't need cached archetype lists here as we aren't iterating, etc). In practice, it seems like we really just need to orchestrate ReadFetch, which is considerably smaller / simpler / less expensive.

This feels inefficient / we're doing double lookups. Why not just if let Some(id) = self.resource_id::<R>() { return id }?

Spawning resources as "normal" entities means that we're relying on the "create new resource entity and let hooks despawn the previous resource entity if it exists" behavior, which imo needs to go (see my previous comment).

I'd rather special case resources in scenes than live in the "resource entities are unstable" world.

It is worth pointing out that from a user-facing perspective, this is strictly worse UX by a pretty wide margin. Harder to read, harder to write, harder to understand, takes up more space, error prone (any additional data you attach here will be replaced the second another scene tries to set the resource). Special casing resources in scenes makes a lot of sense I think.

Agreed: ideally we can avoid any breakage to the representation of resources in scenes.

That might be possible, but I would still like to support the entity notation. If / when people start attaching extra data to resource entities, that should be serializable / deserializable through scenes. The only solution I can think of is to store resources twice (both in entities and in resources). It would look something like this:

// valid
resources: {
  "scene::ResourceA": (
        score: 1,
      ),
  },
},
entities: {
  ... // this does not contain a ResourceComponent<ResourceA> entity
}

// also valid
resources: {
  ... // this does not contain a ResourceA resource
},
entities: {
  4294967291: (
    components: {
      "bevy_ecs::entity_disabling::Internal": (),
      "bevy_ecs::resource::IsResource": (),
      "bevy_ecs::resource::ResourceComponent<scene::ResourceA>": ((
        score: 1,
      )),
      "replicon::Replicate": (), // useful additional components that wouldn't fit in `resources { ... }`
    },
  ),
}

// this would be invalid
resources: {
  "scene::ResourceA": (
        score: 1,
      ),
  },
},
entities: {
  4294967291: (
    components: {
      "bevy_ecs::entity_disabling::Internal": (),
      "bevy_ecs::resource::IsResource": (),
      "bevy_ecs::resource::ResourceComponent<scene::ResourceA>": ((
        score: 1,
      )),
      "replicon::Replicate": (),
    },
  ),
}

What do you think of this?

How would you reconcile the entity-notation version with this comment?

One of the motivators for this change is that we get "free" functionality for resources, in the context of things like entity inspectors. However I think this is a great example of why that "free" functionality would require additional custom handling for resources to make it "good".

An entity inspector would (logically) display this as something like:

entity_id: 11v0,
components: [
    ResourceComponent<ResourceA>(ResourceA {
        score: 1
    }),
    IsResource
    Internal
]

And notably this would be hidden by default because it is Internal.

Is this actually better than having a separate resource section of the inspector that displays it as:

ResourceA {
    score: 1
}

without needing to disable the Internal filter and manually filter down to IsResource?

Of course, you could build that functionality on top of the entity representation. But the ideal UX is very different from what we get by default, and the default UX doesn't really win us much in the majority of cases. That is also true for the scene case (see my other comment).

I'm not in love with the ResourceComponent wrapper. Why not implement Component directly for the resource? This would make it appear nicely (without a wrapper type) in scenes / brp / inspectors, it would make the component type id match the type of the resource, it would make it look nicer in queries, easier to consume when being queried for, would result in less codegen, fewer reflected types, etc, etc, etc.

This was previously attempted, and caused problems with type safety and open questions around overlap between ReflectResource and ReflectComponent. I'm open to reverting back to that design: I didn't consider the codegen concerns.

If you prefer an approach without the wrapper, you can review the first version (#20934).

I'm struggling to see this as a net win for users (or maintainers). I can see a world where we shore things up and the calculus changes, but in its current form I don't feel compelled to merge. The cost is too high and the benefits too intangible.

The Pros

• We get "free" access to entity/component features, such as:
  • Hooks: not really a benefit as the add/remove hooks are already "occupied"
  • Component lifecycle observers: these are nice! but we could easily add equivalent events for resources, and I suspect using these events will be niche.
  • Ability to attach additional components/ data to resources + query for them: I'm not yet sure why we'd want this. I'm guessing we could find use cases, but I suspect they will be niche.
  • Ability to "target" resources with relationships. I'm not sure why we'd want this. I suspect someone could find a use case, but it is probably niche.
  • We get "free" support for resources in tooling like scenes, entity inspectors, and BRP. I don't see this as a particularly big win in practice, given the simplicity of building the custom paths for resources, and the default behaviors often have downsides / are suboptimal (see my other comments)

The Cons

• Resource access is now considerably more expensive and convoluted internally (see my other comments)
• The current design relies on resource entities being unstable. This loses us a lot of the wins of the entity representation (see my other comments).
• Many of the "free" entity / component behaviors are wrong / suboptimal when compared to a custom resource path: entity inspectors, scenes, spawning entities containing the resource component, etc (see my other comments).

Ability to attach additional components/ data to resources + query for them: I'm not yet sure why we'd want this. I'm guessing we could find use cases, but I suspect they will be niche.

This might be different for Bevy since you already get rust traits to configure behavior, but in the case of flecs it's very common to do this: https://www.flecs.dev/flecs/md_docs_2ComponentTraits.html (a trait in flecs is a component added to a component).

It's also used to put components under module (plugin) parents to mirror the type hierarchy, to store component names, reflection data, used by Flecs users to add custom attributes etc.

None of these things need to be stored on a component entity, but once they are it's a nice & consistent way for users to interact with the API :)

Ability to attach additional components/ data to resources + query for them: I'm not yet sure why we'd want this. I'm guessing we could find use cases, but I suspect they will be niche.

This is required for networking by both replicon/lightyear.
Replication resources would involve adding a component such as Replicate on the Resource entity (+ other components to customize replication).

It also very useful to be able to write replication logic once for entity/components and get resource replication for free, as opposed to having to special-case resources.

I could implement it by rolling out my own singleton entity that points to that resource, but it's probably be easier to simply have resources be entities.

I can see a world where we shore things up and the calculus changes,

What would that world look like? Can I tweak the current PR and get it to a state in which you'd agree to merge it, or is it dependent on other efforts?

I'm surprised to see questioning of the utility of resources-as-entities in general. Maybe I'm over-indexing into it, but I feel that some way to express resources-as-entities is really important! I hope you don't mind me adding a couple more real-world motivating examples.

Singleton components

There are many instances of singleton components in my code bases. As I'm developing my web framework, there are a few obvious targets: namely, HTML elements and browser resources that only exist once.

• The browser window and document (among other items)
• The document's <html>, <head>, and <body> elements.

These are currently expressed in my code as components. After all, all of these objects are event targets. I can add an event handler with my Events relationship. And it probably goes without saying that the HTML elements need to exist in the element hierarchy to function properly in my framework.

Consequently, my code base is littered with Single<&Window> params that would be more elegantly expressed as Res<Window>.

The same idea also comes up with items under my control, like a right-click context menu element. There should only ever be at most one ContextMenu component, but it would benefit from relationships, additional components, and lifecycle observers if I want to render it to HTML.

Resource-dependent entities

In bevy_seedling I have an index resource for dynamically-generated sampler pools. (Sampler pools are entities with a unique label.) Currently, this resource is private. This is partly because my crate's API would otherwise expose a correctness trap; removing this resource could leave behind unreachable pools.

If resources were entities, I could make these pools children of the index resource. Despawning the index would therefore necessarily clean up any indexed pools. I could similarly provide a Replace observer to catch that operation. I could then expand on the functionality of this index by using its presence to dictate whether dynamic pools are created in the first place.

Overall, an entity-integrated API would be clearer, simpler, and more correct.

It's true these APIs are largely expressible one way or another without resources-as-entities. And I can understand resistance to the implementation of the PR. But to me, there's a lot of immediate value in the idea itself.

None of these things need to be stored on a component entity, but once they are it's a nice & consistent way for users to interact with the API :)

Yup I agree that being able to add additional behaviors / metadata to resources is nice.

This is required for networking by both replicon/lightyear.

I see the appeal!

What would that world look like? Can I tweak the current PR and get it to a state in which you'd agree to merge it, or is it dependent on other efforts?

It is dependent on resolving the issues I have outlined in my comments. If you can do that in this PR, thats fine by me.

I'm surprised to see questioning of the utility of resources-as-entities in general

I'm not questioning whether or not the utility exists. I'm only making a relative-value judgement: I don't see the utility as high enough to compromise on the concerns I have outlined in my review.

Consequently, my code base is littered with Single<&Window> params that would be more elegantly expressed as Res.

Bevy's Window component is not "unique", as bevy supports multiple windows. I would probably oppose a derive(Resource) on Window.

Resource-dependent entities

I see the appeal!